The present invention relates to distributed component-based computer software applications, and more particularly relates to queued method invocations on such applications.
In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers and other services at a bank, and sales at a business. In these examples, the processing services provided by the server application may update databases of class schedules, hotel reservations, account balances, order shipments, payments, or inventory for actions initiated by the individual users at their respective stations. This is sometimes referred to as client/server computing.
In a form of client/server computing sometimes known as xe2x80x9cdistributed objects,xe2x80x9d the server application is developed as a set of components conforming to an object-oriented programming (OOP) model, such as the Microsoft Component Object Model (COM) and Distributed Component Object Model (DCOM), the IBM System Object Model (SOM), the Object Management Group""s Common Object Request Broker Architecture (CORBA), and others. Object-oriented programming generally has advantages in ease of programming, extensibility, reuse of code, and integration of software from different vendors and (in some object-oriented programming models) across programming languages.
In object-oriented programming, programs are written as a collection of object classes which each model real world or abstract items by combining data to represent the item""s properties with methods (e.g., program functions or procedures) to represent the item""s functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance.
Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related methods of the object. In other words, the client programs do not access the object""s data directly, but must instead call methods on the object""s interfaces to operate on the data.
Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
In client/server computing with xe2x80x9cdistributed objects,xe2x80x9d the client program on the user""s computer typically uses xe2x80x9creal-timexe2x80x9d or synchronous processing mechanisms to remotely invoke methods on the server application""s objects that reside on the server computer, such as the remote procedure call (xe2x80x9cRPCxe2x80x9d). In a typical remote procedure call, object services of the operating system compile an interface definition language description of a server application object to generate a local xe2x80x9cproxyxe2x80x9d for the server application object on the client computer. The client software invokes methods of the remote server application object by issuing ordinary local procedure calls directly to the proxy. The proxy, in turn, utilizes RPC services to convey the procedure call to the actual server application object on the remote server computer. The RPC services marshal values for call parameters into a network message, and send the message via network protocols to the server computer. At the server computer, the RPC services unmarshal the call parameters and issue the call to the proper server application object method. The RPC services also marshal and unmarshal return values from the server application object method back to the client program via a network message.
The RPC services thus handle all the intricacies of network communications effectively xe2x80x9cbehind the scene,xe2x80x9d such that the client program invokes the remote method in a similar manner to making a local procedure call. Like a local procedure call, execution of the client program is suspended (also known as xe2x80x9cblockingxe2x80x9d) during the RPC method invocation until the method completes and returns. This results in a synchronous flow of execution among the client program and server application objects.
Although appropriate to many applications, real-time method invocation models like the RPC fail to adequately meet the needs of other applications due to a number of limitations as to availability, network transmission costs, lack of priority, object lifetime, and reference locality.
As to availability, real-time method invocation models require that the server application object is available at the time that the client program issues a call to one of the object""s methods. If not available, then the real-time method invocation cannot take place. In reality however, server application objects may not be available due to network failures, or due to the server computer being overloaded with work. In some cases, the server computer may be off-line for a certain duration (e.g., due to upgrades or maintenance), or may only come on line at certain times of the day. Further, if any server application object is not available in xe2x80x9creal time,xe2x80x9d no part of the work (including by available server application objects) can complete. This problem is exacerbated in the case of complex operations involving multiple nodes (i.e., computers on a network). For example, a process that requires access to four independent objects on separate nodes each available about 90% of the time, is actually available only about 66% of the time (since 90%4=65.61%).
Additionally, some client computers are only occasionally connected to a network, and thus unable to issue real-time method invocations for a majority of the time. A good example of such occasionally connected client computers are laptops, notebooks and handheld computers of mobile users, which are estimated to now make up more than 50% of new computer purchases.
The availability requirement of the real-time method invocation model also means that the server computer(s) must be configured with sufficient capacity to handle the peak demands by interactive users of the server application. As a result, the typical system is configured with server computers that are underutilized most of the time, and are still over-utilized at other times (e.g., when actual load exceeds expectations).
For these reasons, the real-time method invocation model is not well suited to computing environments with limited availability, mobile users, large number of nodes, or high variance interactive user loads.
As to network transmission costs, each real-time method invocation via an RPC requires a round-trip network communication which imposes significant network transmission costs, such as processing time for marshaling and unmarshaling of call parameters, processing in the network protocol stack, and transmission time. Moreover, the client may need to invoke many methods of a server application component to perform useful work, thus multiplying the network transmission costs. Modern object-oriented design techniques, in particular, tend to result in many procedure calls with relatively few parameters in each call. A typical such object, for example, is designed such that a client first calls several xe2x80x9cproperty setxe2x80x9d methods to set up an operation, and then invokes a method to process the operation. Consequently, a large amount of the time can be spent in network overhead. These network transmission costs can render real-time method invocation models less suitable to some applications.
As to priority, calls according to typical real-time method invocation models are handled as they arrive on a xe2x80x9cfirst-come, first-servedxe2x80x9d basis, without any notion of priority.
As to object lifetime, server application objects tend to have long lifetimes in real-time method invocation models. In typical distributed-object client/server computing, the server application object exists on the server computer from the time of creation by the client until the object is released. The object spends much of this time simply waiting for the client to invoke the object""s methods, and on the network transmission costs from returning method results until a next method invocation from the client. Meanwhile, the object consumes server computer resources, including memory and processing overhead of the execution environment. The server application object effectively xe2x80x9cwakes upxe2x80x9d and xe2x80x9csleepsxe2x80x9d at least once per method call. This server application object xe2x80x9coccupancy timexe2x80x9d is an impediment to rapid cycling of server objects, and limits server application scalability.
As to reference locality, many parts of computer systems (e.g., the processor cache and the virtual memory working set) rely on reference locality to achieve performance gains. Highly localized applications, e.g., objects or application code that execute straight through using locally available data, therefore have reference patterns that yield better performance. By contrast, applications with objects distributed over multiple server computers that use real-time method invocations like the RPC have poor reference locality. For example, a server object is created by the first real-time method call, and often spends much of its lifetime awaiting subsequent real-time method calls. After processing each method call, the server object is typically displaced from the processor cache and sometimes falls out of the system""s virtual memory working set between calls. The real-time method invocations thus limit the application""s transaction processing volume.
An alternative to xe2x80x9cdistributed objectsxe2x80x9d that addresses some of the availability limitations of a real-time RPC method invocation is a form of client/server computing sometimes known as xe2x80x9cmessage oriented middlewarexe2x80x9d (MOM). In MOM, a client application communicates with a remote server application by sending messages to a message queue. The server application, which may run at a later time than the client application, retrieves and processes the messages from its message queue. The server application can return results of this processing to the client application by sending messages to a same or separate message queue for processing by the client application. Such queued messaging has the advantage that the client and server applications need not be available simultaneously, and need not have concurrent lifetimes.
Traditional MOM products, however, also have a number of limitations. One limitation is that the client application and server application typically formats the messages on their own as a linear stream. More specifically, the client and server applications must provide their own marshaling and unmarshaling of data from this stream. No marshaling support is provided in the queued messaging infrastructure.
A further limitation of the traditional MOM is that the client application and server application communicate to the queued messaging infrastructure using a vendorspecific message queuing application programming interface (API). In other words, the client application and server application send messages to a message queue via explicit calls to the message queuing API. This is yet another set of APIs for developers of the client/server applications to learn. For example, the MQI (for MQSeries API) is the API of IBM""s MQSeries message oriented middleware product. Other MOM product vendors, e.g., Microsoft (Microsoft Message Queue (MSMQ)), Covia (Communications Integrator), Peerlogic (PIPES), Horizon Strategies (Message Express), and System Strategies (ezBridge), have different message queuing APIs.
Additionally, customers of a MOM product (such as, an information technology (IT) organization) for various reasons create a separate API layer over the vendor-provided message queuing API. One reason is that the IT organization doesn""t want its application developers deciding which parts of the message queuing API to use and how to use the API. A second reason is that the vendor""s message queuing API is too rich, too complex, or offers too many options to the application developers. The IT organization thus creates their own API layer in an effort to simplify the API for its application developers. As a result, most of the developers are forced to learn both the vendor""s message queuing API and the IT-provided API. A third reason is that the IT organization doesn""t want its applications to be dependent on any one vendor""s message queuing API or MOM product, and hopes to retain the flexibility to switch vendors at a future time. This often prevents the IT organization from fully exploiting the features of the MOM product. This phenomenon delays implementation of applications with a MOM product and sometimes makes it difficult for the IT organization to exploit newly introduced features of the MOM product.
Yet another limitation of traditional MOM products is sub-optimal performance in some configurations. In particular, applications and application objects can communicate locally via method calls with extremely low processing time cost, especially when in a same process. Applications and application objects that communicate through a message queuing API require processing through a queue manager, even if the applications or objects are in the same or similar environments, such as a same process.
The present invention provides a capability for a client of an object to issue and the object to receive method invocations on a queued basis using normal call semantics of an object model, without use of a message queuing API. More specifically, the client uses the normal semantics of the object model to create the object, call the object""s methods, and release the object. The object framework or execution environment supplies services to automatically queue the method invocations, and at a potentially later time issue the queued method invocations to the object. Meanwhile, the client is allowed to continue execution asynchronously from the invoked method. The object, in turn, has the queued method invocations issued to its interface(s) per normal call semantics, and processes then returns a value from the method again using normal call semantics. The application developer thus need not program the client and the object to use a message queuing API for queued processing as per traditional message oriented middleware, and avoids the need to learn such APIs.
According to one aspect of the invention, an object can receive both real-time and queued method invocations on a common interface. Real-time method invocations are delivered to the object via a local procedure call or remote procedure call to the interface. Queued method invocations are queued in a queued method invocation facility, then delivered via a local procedure call from the facility to the object""s interface. No distinction between the real-time and queued method invocations is apparent to the object. The object therefore can be run in either a real-time synchronous environment or a queued asynchronous environment without modification. The object is figuratively xe2x80x9cunawarexe2x80x9d of the real-time or queued nature of its environment, and xe2x80x9cagnosticxe2x80x9d as to the manner in which the methods on its interface are invoked.
According to another aspect of the invention, the object framework or environment also provides automatic marshaling support for queued method invocations. A client issues queued method invocations to an object via a system-provided proxy and stub or wrapper that is compiled from an interface definition language description of the object""s interface to implement appropriate marshaling of call parameters and related data to and from queued messages.
According to yet another aspect of the invention, the method invocation queuing facility includes a method invocation recorder at a client-side and a method invocation player at the object-side of the client-object interaction. The method invocation recorder receives a set of possibly more than one method invocations from a client to be forwarded as a batch to the method invocation player. For example, the recorder can collect a number of queued method invocations made by the client on the object as part of a transaction, and not forward the method invocations until the transaction commits. The method invocation player retrieves the queued method invocations in order from a method invocation queue, and issues the method invocations to the objectxe2x80x94potentially as part of another transaction involving the object.
According to a further aspect of the invention, an object that supports queued method invocations conforms to the limitation that its methods may have only input parameters and may not return application-specific information. The queued method invocations can then be issued as one-way communications from the client to the object that do not require the client to wait in real-time or synchronous execution for results of the method invocation. The object can provide results of processing the queued method invocations by issuing real-time or queued method invocations to a results object specified by an input parameter from the client.
Additional features and advantages of the invention will be made apparent from the following detailed description of an illustrated embodiment which proceeds with reference to the accompanying drawings.